One of the limitations of various versions of the Internet Protocol (IP) such as IPv4, is that it has a limited address space. Consequently, in order to conserve addresses, enterprises and other administrative domains have resorted to using private addresses. Private addresses are network addresses in which the IP address falls within the ranges of 10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255, or 192.168.0.0-192.168.255.255.
Private addresses that are assigned by an administrative entity within a private network only have relevance within the respective private network. Accordingly, such private addresses are typically not visible outside the private network. An advantage of using private addresses, however, is that different private networks may assign the same private IP address to hosts within their respective private networks without any concern of conflict. On the other hand, a Network Address Translator (NAT), which can also function as Network Address Port Translator (NAPT), can be used when a host that is assigned a private address within a private network intends to send an IP datagram to a host that is outside the private network of the sending host. A NAT transforms a private IP address (and possibly other selected fields within the datagram) into a public IP address prior to the IP datagram being sent outside the private network associated with the NAT. With the added functionality of the NAPT, the NAT can further transform ports, such as Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) ports, from the private network to the public network. Similarly, when an IP datagram is sent from a host that is outside the administrative domain associated with the NAT to a host with a private address, then the NAT transforms a public IP address to a private IP address and, with the NAPT added functionality, a port in the public network to a port in the private network.
In addition to providing address and port translations, the NAT can communicate with a firewall and/or gateway that operate as a security mechanism to an associated private network. In this regard, the firewall/gateway can operate to provide security in that, as before incoming datagrams pass through a translation process of the NAT and/or after outgoing datagrams pass through a translation process of the NAT, the firewall/gateway can be capable of qualifying such datagrams. In addition, by translating private IP addresses into public IP addresses, the NAT can be capable of providing a measure of privacy for those associated with the private IP addresses.
The use of private addresses within a private network and use of a NAT at the edge of a private network has been widely adopted and deployed within enterprises. There are, however, drawbacks associated with use of a NAT. In this regard, consider a private network comprising, connected to or otherwise associated with a mobile network, such as a general packet radio service (GPRS) network. In such instances, a terminating node, such as a mobile terminal, communicating across the mobile network can generally initiate a packet-switched (e.g., IP) connection with an IP device across the NAT. An IP device typically cannot, however, initiate a similar packet-switched connection with the terminating node across the NAT. In addition, because terminating nodes typically lack a static and public identity like a fixed IP-address, IP devices often cannot identify a desired terminating node to the NAT.
Mobile networks are typically configured in a manner that prevents an IP device from initiating a packet-switched connection with a respective terminating node for a number of reasons. Firstly, depending upon the mobile network topology, enabling IP-connectivity to terminating nodes within the mobile network can consume an undesirable amount of resources or reduce performance of the mobile network even when there is no IP traffic across the mobile network. Secondly, in the mobile network, as in many private networks, there may be more terminating nodes than available IP addresses. As such, the mobile network may include a NAT, dynamically allocated IP addresses and/or private IP addresses. Thirdly, the security needs and policies of many mobile networks require that various IP traffic be prevented from passing into the mobile network. Such an instance also often leads to the use of the NAT, particularly when the mobile networks include an associated firewall/gateway.
Typically, clients that use the TCP/IP protocol suite and are located in a private network are able to contact and connect to servers that use the TCP/IP protocol suite that are located in the public network. Connectivity in the opposite direction, i.e., clients in a public network connecting to servers in a private network, is usually much more complicated and often not possible for two reasons: (1) because nodes in the private network have private, non-routable IP addresses that are meaningless to clients outside the private network and cannot be used by the clients, and (2) because firewalls are often configured to block all such connections for security reasons.
Several solutions have been proposed to address this NAT/firewall traversal problem. In one solution, a node acting as a NAT/firewall exposes a port associated with the node's own public IP address and incoming connections to this port are translated and relayed as incoming connections to the desired server. Additionally, many systems offer solutions using intermediary nodes, such as agents, proxies, application gateways, virtual private network (VPN) gateways, and the like. These solutions depend on configuring one or more intermediary nodes (e.g. NAT, firewall, VPN gateway, application gateway, etc.) located between the client and the server to mediate so that the connection between the two nodes is successful. Even though these solutions enable NAT/firewall traversal, there are drawbacks in requiring an intermediary node to assist the connection between the client and the server. For example, generally operators and/or administrators, rather than users, control these intermediary nodes, resulting in little or no control by the users. Also, network administrators or users would have to reconfigure NATs/firewalls often to enable communications as new servers are added to the private network. Thus, it would be desirable to have a system and method that would enable NAT/firewall traversal without requiring special configurations of intermediate network nodes and without requiring any modifications in existing client and server TCP/IP applications in the end nodes.